很多同学最怕听“建模型”仨字。尤其是建立“业务分析模型”。往往自己辛辛苦苦搞的LR、SVM、CNN被业务方狂喷：
你这都是啥东西！
脱离业务！
不切实际！
所以到底什么是“业务分析模型”，又该怎么建？我们今天系统讲解一下。
所以，首先得把SWOT，PEST，4P之流的垃圾扫出“模型”队伍。因为这些玩意有逻辑、有目标，但很难用数据进行论证。不信你看那些什么SWOT，PEST的报告，四个框框里都没几个数字，即使有数字也很难论证：到底90后比80后减少5000万会对我们业绩产生几百万影响。无法量化计算的，不算分析模型。它们只是拿来美化ppt的。业务分析模型的重点，在“业务”两个字。得让业务参与得进来，看得懂，能应用的，才叫业务分析模型。显然，我们不能指望产品经理、销售、运营、售后、物流的人去学《机器学习》《数学建模》《统计学》《python编程》所以数据分析师们经常打交道的算法模型就不要在这里用了——业务看不懂，参与不进来，问题解决不了，当然会喷没有用。有的同学会疑惑：可我的领导只会提“建个模型”，说不出是业务模型还是算法模型，我怎么区别呢？有个最简单的原则是：非技术出身的领导，90%以上讲的是业务模型（剩下10%是他在朋友圈看了个协同过滤、神经网络之类的名字，然后临时起意想搞一下）。当单个指标不能全面描述现状的时候，就得一系列指标有逻辑地呈现，以全面描述现状、发现问题，这是所谓：现状描述模型。业务常见逻辑有2种：串联式、并联式。串联式模型用于描述一个前后分n个阶段的流程，需要完成一步再到下一步。从流程起点开始，到终点结束；并联式模型描述一个任务分开同时由各个线独立完成。从总目标开始，到执行任务的最小单位结束（如下图）。因此梳理业务流程的时候，需要关注业务上下游部门、兄弟部门是如何协同的，从而构建出来。实际业务流程，可能既有串联，又有并联，比如我们常说的杜邦分析法，就是如此（如下图）：现状描述型模型的最大作用是：清晰责任，暴露问题。因为一般各个子部门，上下游部门各有自己的KPI，因此监控进度、复盘成果的时候，哪个环节掉链子一清二楚。所以在销售管理、运营管理中用得特别多。但注意：现状=/=问题，现状+标准=问题。因此只有标准单一且明确的时候才能直接看出问题来。如果标准本身很复杂，则需要更进一步的手段。如果判断一个指标好坏的标准只有一个，比如成本、利润，这时候是不需要模型的。大家都知道成本越低越好，利润越高越好，业务完全可以直接给判断标准。如果判断业务好坏需要2个标准，且这两个标准相关度低，这时候可以用矩阵模型来进行分类。常见的重要紧急矩阵，波士顿矩阵，质量/数量矩阵，都是这个原理（如下图）。如果判断标准增加到3个以上，判断标准相互交叉情况太多太多，再用肉眼观察就很难判断谁好谁坏，这时候可以用DEA方法或者AHP来判断，相比之纯机器学习方法，DEA方法含义更简单直接，AHP方法有专家参与，都更容易被业务接受。在给定业务限制条件的情况下，经常出现最优化问题。比如给定了各个部门工时成本，求一个最优任务分配。这时候就是工作计划模型。最常见的就是解线性规划，在工作调配的时候用得非常多（如下图）。所有预测的基本假设，都是：未来发生的规律和过去一样，过去的场景会在未来重现。所以业务做预测的时候，常常会假设一些业务参数是固定的，然后推测未来情况。在一些发展稳定的行业里，这些假设常常很准。但注意，有三种情况下假设可能失效。这时候要么更换预测方法，要么做足预案，提前准备后路。单纯指望预测100准，不论是业务模型还是算法模型，都会出问题。看完以上，有同学会好奇：看起来业务模型能做很多事啊，那什么时候用算法模型呢？注意：算法模型本身的强项，就不是解决经营问题。算法模型的强项是图像识别、语义识别、复杂场景下动态规划。这些才是算法该发挥用处的地方。1、商品有固定的搭配。比如治疗感冒就是VC+银翘，这叫：固定业务逻辑，这时候是不需要算法来推荐的，直接按业务逻辑走就好了。2、商品无固定搭配，但业务方想推。比如保健品利润高，无论如何业务方都想推保健品，这叫：强业务关联。这时候也不需要算法来推荐，而是业务方得创造话术、广告、卖点、销售技巧，千方百计地去洗脑，特别是针对大爷大妈洗脑。3、商品无固定搭配，且业务方无明确目标。比如天猫淘宝抖音这种，SKU数以亿计，这时候业务逻辑完全理不清，就可以上推荐算法，而且推荐算法目标常常是GMV最大，用户活跃时长最长一类。类似地，找算法模型的应用场景，得主动回避开固定业务逻辑、强业务关联——找那些业务不知道、不清楚情况、无力加以控制的场景。这时候可以大胆让业务逻辑退居二线，尝试用算法解决问题。可以名正言顺地跟业务说：这就是个黑箱。我们观察结果就好了——反正他们也没更好的办法，如果能做出成绩来，就是大功一件。